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[57] ABSTRACT 

Computer integrated telecommunication systems are dis- 
closed that provide a message exchange interface that trans- 
fers data and control requests generated by applications 
running on a computer system directly to a telecommuni- 
cations unit that is adapted to respond to the data and control 
requests generated by these application programs. In 
particular, PBX systems are disclosed that include message 
exchange interfaces that provide fault tolerant operation and 
that directly map application programs running on a com- 
puter system into the controller element of the PBX system. 
Further systems are disclosed that provide message 
exchange interfaces that allow the efficient transfer of audio 
signals between a computer system and a telecommunica- 
tion unit. 

21 Claims, 5 Drawing Sheets 
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COMPUTER INTEGRATED PBX SYSTEM 

HELD OF THE INVENTION 

The present invention relates to systems and methods for 
computer integrated telephony and, more particularly, to 
systems and methods for integrating private branch 
exchange (hereinafter "PBX") systems with local area net- 
work (hereinafter "LAN") servers. 

BACKGROUND OF THE INVENTION 

The integration of telecommunication equipment with 
data processing equipment provides for powerfiil tools that 
coordinate the advanced features of digital telephony with 
the computer processing power of digital computer net- 
works. For example, computer integrated telephony (C\'V) 
systems exist that integrate PBX systems with LAN sys- 
tems. These PBX CIT systems provide advanced call control 
and processing. For example, these CIT systems can run 
applications that detect incoming telephone calls, employ a 
caller ID function to determine the identified source of the 
incoming call, pass the source identification information to 
a computer database application program that employs the 
source identification as an entry point to the database. From 
the database, the CIT system can collect relevant cxistomer 
records such as the invoice statements. The CIT system at 
that time can transfer both the incoming call and the asso- 
ciated data records to a customer service agent that is most 
suited for handling this incoming call. For example, if the 
invoice records show that the account associated with the 
call is overdue, the CIT system transfers both the incoming 
call and the relevant invoice data record to an available 
customer service agent in the billing department of the 
company. 

The CIT systems that exist today include a PBX system 
that connects to a network server. The PBX system performs 
the telecommunication functions which include establishing 
circuit connections between calls from the public telephone 
system and the individual extension lines within an office. 
The server performs the data processing applications which 
can include maintaining databases and nmning client/server 
applications. The interface between the PBX and the server 
establishes a physical and logical connection between the 
server and the PBX that allows for the operation of CIT 
systems. 

The physical connection between the PBX and the server 
is typically a conventional computer interface that includes 
an interface card located in the PBX, an interface card 
located in the server and a cable connection that extends 
between these two interface cards. The interface cards 
typically implement a conventional data communications 
protocol such as X.25 or ISDN. Through this channel, the 
PBX and the server can exchange data for coordinating the 
activities of these' two systems during operation of CIT 
system applications. 

The logical connection between the PBX and the server 
determines how messages are exchanged across the physical 
interface. Typically, a client/server application running on 
the computer network generates either requests for actions 
or requests for instructions for the PBX system. The client 
passes these requests on to the server. The server has a 
translator program that translates the message requests from 
the application program into commands that can be used to 
operate the PBX. These commands are sent to a software 
driver that puts the commands into a format suitable for 
transmission over the data channel, such as the ISDN line or 
X.25 line. The PBX system receives through its interface 
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card the commands and performs the functions as dictated. 
The PBX then transmits status messages back to the server 
- system \yhich translates the PBX messages into a format that 
the application program can understand and the server sends 

5 the translated messages to the application program. The 
application program determines from the translated mes- 
sages what data records the application program needs to 
access and proceeds to route the data records to the appro- 
priate client computer and to send further instructions to the 

10 PBX system to route any associated incoming calls to the 
telephone associated with that client's computer. 

Although the above systems work to integrate data pro- 
cessing equipment with telecom mimications equipment, the 
. integration through the physical and logical connections is 

15 often perplexing and difficult to create and maintain. Firstly, 
most PBX architectures are proprietary, therefore the physi- 
cal connection between the server and the PBX differs 
depending on the vendor. For example, an EtherNet port, 
such as the one found on the NEAX 2000 from Nec 

20 America, will be different from the ISDN BRI link 
employed by AT&T's Definity system. Computer network 
managers that have to integrate the PBX system into the 
local area network often find the link between the server and 
PBX to be both cumbersome and unreliable. 

Moreover, these present systems are dependent upon the 
proper operation of the network LAN server. In the event 
that the LAN server crashes, the CIT system application thai 
operates the PBX system is brought down. Similarly, any 
time the computer network manager wishes to reinitialize 

■^^ the network server, those CIT applications that operate the 
telecommunication systems will also be brought down. 
Accordingly, the present systems are subject to failure and 
are difficult to maintain. A further difficulty exists, in that the 
development of CIT applications is made difficult by the 
proprietary PBX driver that translates messages from client/ 
server applications into commands suitable for implemen- 
tation by the PBX system. In particular, as each PBX driver 
is typically a proprietary software system, the development 
of standard applications is difficult, if not impossible. 

Accordingly, it is an object of the present invention to 
provide CIT systems that provide an improved interface 
between telecommunication equipment and data processing 
systems. 

It is a particular object of the present invention to provide 
a PBX system that more easily integrates with the server of 
a local area network. 

It is a further object of the present invention to provide a 
• LAN — integrated PBX system that has improved fault tol- 
50 e ranee. 

It is an additional object of the present invention to 
provide a CIT system that has greater performance and 
improved reliability. 
These and other objects of the present invention shall be 
55 made more clear by the following description that references 
figures having reference numbers wherein like reference 
numbers refer to the same elements. 

SUMMARY OF THE INVENTION 

60 . Computer integrated telecommunication systems are dis- 
closed that provide an interface that transfers data and 
control requests generated by applications running on a 
computer system directly, and unchanged, to a telecommu- 
nications unit that is adapted to respond to the data and 

65 control requests generated by these application programs. In 
particular, PBX systems are disclosed that include calling 
interfaces that directly map telephony enabled application 
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programs into the coatroUer element of a PBX system. The system further can include an exchange interface that 

Further systems are disclosed that provide interfaces that couples to a second system according to the invention for 

allow the efficient transfer of audio signals between a exchanging message signals between plural ones of these 

computer system and a telecommunication unit and between systems. Preferably the exchange interface comprises an 

a computer system of a first network and a computer system 5 SCSA, Signal Computing System Architecture, interface to 

of a second network. allow the daisy chain interface of plural systems. In a further 

In one aspect, the invention is understood as systems that embodiment of the invention the system also includes an 

are adapted for being integrated into the server of a computer audio data transfer element that allows the transfer of data 

network. The systems include a carrier interface for coupling representative of audio signals to the integrated computer 

to a plurality of carrier lines suitable for transmitting signals server. 

to a telephone. The carrier interface can include a trunk a further aspect, the invention can be understood as 

interface for coupling to one or more trunk lines, or a network server systems that include a message bus for 

subscriber loop interface for coupling to a plurality of . carrying message signals, a server controller element for 

extension hnes wherein each extension line is of the type controlling the transfer of message signals across the mes- 

which is suitable for canrying signals to a telephone. In a ^5 sage bus, a branch exchange element that includes a bus port 

preferred embodiment the carrier interface includes both a connected to the message bus of the server to form a data 

trunk interface and a subscriber loop interface. The system path therewith, a trunk interface for coupling to a trunk line, 

can further include a server interface having a bus port a subscriber loop interface for coupling to a plurality of 

adapted for connecting to a bus slot of the server to form a extension lines of the type suitable for carrying signals to a 

data path with the server, a controller element that transfers 20 telephone, a controller element in electrical circuit with said 

message signals across the data path and that generates bus port for transferring the message signals across the data 

control signals responsive to the message signals, and a path and for generating control signals responsive to the 

switch element that is connected into an electrical circuit message signals and a switch element that is an electrical 

with the controller elements and that establishes, in response circuit that is in electrical circuit with the controller element 

to the control signals, circuits between the plural extension 25 establishing, in response to the control signals generated 

lines and the trunk lines. In this way, the system according by the control element, circuits between the plural extension 

to the invention includes an interface that directly maps lines and the trunk line. 

telephony enabled application programs into the control Network server systems according to the invention can 

program of a telecommunication system. This allows the also include control elements that have audio data transfer 

telephony enabled application to have direct access and 30 elements for transferring data representative of voice signals 

control over the integrated telecommunications equipment. to the server controller element. The server controller ele- 

In a preferred embodiment of the invention, the controller nient can also include a play audio element that has a data 

element includes a processor element and a memory element memory means for storing audio files of audio information 

that includes a calling interface element, typically a software and an audio file transfer element for transferring audio files 

program, that operates the processor element to generate the 35 to the branch exchange element. Moreover, the network 

control signals in response to the message signals which are server system can also include an internetwork interface 

transferred unchanged across the data path to the server. The element that allows for the transfer of audio files to a second 

calhng interface typically includes a switch element that network system, 

responds to a message-type signal included: the message In a further aspect, the invention can be understood as a 

signal, and responsive to the message-type signal instructs 40 telecommunication system that is adapted for being inte- 

the processor to generate the control signals. In a further grated into a stand alone computer. The system includes a 

preferred embodiment of the invention the calling interface trunk interface for coupling to a trunk Line, a subscriber loop 

element operates the controller element in response to interface for coupling to a plurality of extension hnes of the 

message signals which are CSTA, Computer Supported type suitable for carrying signals to a telephone, a computer 

Telephony Application, compliant message signals. The 45 interface having a bus port adapted for connecting to a bus 

calling interface can further include an element for gener- slot of the computer to forth a data path with that computer, 

ating message signals for transfer to the server interface. a controller element in electrical circuit with the bus port for 

Preferably the element for generating the message signals transferring message signals across the data path and for 

includes an element for generating CSTA compliant mes- generating control signals in response to the message signals 

sage signals, 50 and a switch element that establishes, in response to the 

In one embodiment of the invention, the calling interface control signals generated by the controller element, circuits 

element is a software program element that is preferably between the plural extension lines and trunk lines, 

stored in read only memory element which is onboard a BRIEF DESCRIPTION OF TIIE FIGURES 
circuit card assembly that comprises a telecommunication 

system. In a further embodiment of the invention, the 55 ^ ^ functional block diagram of a CIT system 

controller element also includes a memory element for accordmg to the present mvention; 

storing a call control program element that implements the P^^- 2 is a functional block diagram of a PBX system 

telecommunication functions of the system. Preferably the according to the present invention suitable for integration 

controller includes an onboard power supply element for i^to the. server of a local area network; 

supplying power to the controller element and the memory 60 3 is a block diagram of the software and hardware 

elements to thereby provide onboard call control indepen- components of a CIT system according to the present 

dent of the functioning of the integrated computer system. invention; 

Accordingly, telecommunication functions such as confer- FIG, 4 depicts the data sUucture of one message unit data 

ence calling, call transfers, and call holding can be accom- structure employed by the software depicted in FIG. 3; and 

plished without support from the integrated computer equip- 65 FIG. 5 depicts an intemetworked system for transferring 

ment. This provides a system having improved fault tolerant data between two or more systems according to the present 

operation. invention. 
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DETAILED DESCRIPTION OF THE 
ILLUSTRATED EMBODIMENTS 

The following describes certain exemplary embodiments 
of the invention disclosed herein that provides computer 
systems that include highly integrated telecommunication 
equipment. The highly integrated systems according to the 
invention provide a message exchange interface that trans- 
fers data and control requests generated by applications 
running on a networked computer system directly to a 
telecommunications unit that is adapted to respond directly 
to the data and control requests generated by these appUca- 
tion programs. Such high integration achieves mapping of 
application programs directly into the controller element of 
the telecommunication equipment that is integrated into the 
server system. Other advantages of applicants' invention are 
set forth herein with still more advantages being obvious to 
one of ordinary skill in the art of telecommunications and 
computer engineering. 

FIG. 1 depicts a CIT system 10 according to the invention. 
The system 10 includes a host element 12, depicted as a local 
area network server, a telecom unit 14 that includes a host 
interface 44, telephone units 16, a trunk jack 18 that con- 
nects to trunk lines 20, a transmission path 24, a subscriber 
line interface 26 that connects via transmission path 28 to the 
telephone units 16, a message exchange interface 30, a 
network interface 38, a network bus 40, and client elements 
42. 

As depicted in FIG. 1, the CIT system 10 is an integrated 
system that includes a computer network system and a 
telecommunication unit in order that application programs 
running on the network can interface to and control the 
telecommunications unit. Specifically, as illustrated in FIG. 
1, each client element 42 connects via the network btis 40 to 
the network interface 38. Accordingly, the host 12 collects 
and controls transfer of data through the network computer 
system. As further depicted in FIG. 1, the telecommunica- 
tion equipment, including telephones 16 and the trunk lines 
20, interface with the telecom unit 14. Within the host 12 the 
telecom unit 14 and the network interface 38 connect via the 
message exchange interface 30. Through the message 
exchange interface 30 the network system can exchange data 
and command signals with the telecom unit 14. Accordingly, 
an application program running on a client element 42 can 
interface via the network interface element 38 with the 
telecom unit 14 for passing data, requests and commands to 
control the operation of the telecommunication equipment, 
such as the telephone unit 16, 

Although FIG. 1 depicts a networked CIT system, it will 
be apparent to one of ordinary skill in the art of telecom- 
munications and computer engineering, that the present 
invention can be practiced with stand alone computer sys- 
tems. Other configurations of CIT systems can be practiced 
with the present invention, without departing from the scope 
thereof. 

In the CIT system depicted in FIG. 1, as will be explained 
in greater detail hereinafter, the message exchange interface 
30 is an interface for network applications, including client/ 
server applications, that transfers network commands and 
data from the network to the telecom unit 14. The telecom 
unit 14 includes a host interface 44 adapted to receive 
network commands from the message exchange interface 30 
and to respond to the network commands to control the 
operation of the telecommunication equipment. 
Accordingly, the CIT system 10 includes a telecommunica- 
tion system-lo-host connection that logically and physically 
integrates the telephony and computer applications and 
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thereby provides direct mapping between server applica- 
tions running on the computer network and the telecommu- 
nication functions provided by the telecom unit 14. The 
invention therefore provides a telecom unit interface that 

5 operates on server application message units in its native 
mode. Accordingly, no translation of data and commands is 
necessary during transfers between the host 12 and the 
telecom unit 14. This provides simpler, less expensive CIT 
systems and further provides an improved development tool 
for developing CIT applications. 

In a preferred embodiment of the invention, the host 
interface 44 includes an onboard control element that 
receives data and commands &om the host 12 and, in 
response, operates the telecommunications equipment. 
Similarly, the host interface 44 transfers data, status and 
other information generated by the telecom unit 14 to the 
host 12. As will be explained in greater detail hereinafter, the 
onboard control element of the host interface 44 provides a 
fault -tolerant CIT system. However, it will be apparent to 

20 those of ordinary skill in the art of telecommunications and 
computer engineering that alternative system configurations 
can be practiced with the present invention without depart- 
ing from the scope thereof. 
The CIT system 10 depicted in FIG. 1 includes a host 

25 element 12 which is typically a local area network (LAN) 
server that operates as a file server for running via the bus 
40 client/server applications with client elements 42. One 
preferred server 12 is a conventional PC compatible file 
server having an ISA bus slot interface and being of the type 

30 commonly used for running commercial local area networks 
such the Novell Netware Network System. However, it will 
be apparent to one of ordinary skill in the art of telecom- 
munications and computer engineering that server 12 can be 
any data processing unit suitable for running computer 

35 applications, whether network applications or not, and for 
providing a physical interface with the telecom unit 14 for 
exchanging data and command signals therebetween. 

The depicted telecom imit 14 is a PBX system according 
to the invention that includes a host interface 44 with an 

40 onboard controller for exchanging data and commands 
directly with server 12 and for operating the switching 
functions to establish and maintain telephone calls. Such a 
PBX system according to the invention can be physically 
and logically integrated into a LAN server element, or stand 

45 . alone computer, running telephony enabled applications to 
thereby allow the telephony enabled applications to directly 
communicate with the onboard controller to direct the 
operation of the PBX system. The depicted PBX telecom 
unit 14 creates circuit connections between the trunk lines 

50 20 and the subscriber telephone units 16. In a preferred 
embodiment of the invention, the telecom unit 14 is an 
electrical circuit card assembly dimensionally adapted for 
fitting within a PC compatible file server and having an ISA 
PC bus interface for connecting into an ISA bus slot and for 

55 exchanging data between the telecom unit 14 and the server 
12. 

The depicted telecom unit 14 is a PBX system. However, 
it will be obvious to one of ordinary skill in the art of 
telecommunications and computer engineering that the 

60 invention is not to be limited to a depicted embodiment and 
shall be understood to encompass other PBX systems that 
include an interface that directly exchanges data and com- 
mands with a telephony enabled application program and 
shall be understood to particularly include PBX systems that 

65 provide voice recognition, audio play and record, audio 
signal analysis and other similar functions. Furthermore, it 
will be obvious to one of ordinary skill in the art of 
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telecommunications and computer engineering that the 
invention can be practiced with other telecommunications 
systems that exc&ange information with an application 
program, including any device that switches or multiplexes 
audio signals, observes audio signals or analyzes audio 
signals. 

The PBX telecom unit 14 connects to the subscriber 
telephones 16 via a standard subscriber loop interface which 
will be described in greater detail hereinafter. Each tele- 
phone unit 16 can be a conventional analog telephone unit, 
a digital telephone unit, a digital data device, or any other 
piece of data communication equipment that can connect to 
the subscriber interface of a PBX. The telecom unit 14 
further connects to. the trunk lines 20. The trunk hnes 20 can 
be conventional analog telephone trunk lines of the type 
commonly provided by the public switching telephone net- 
work (PSTN). The telecom unit 14 can also be adapted to 
connect with other carrier systems including the T carrier 
systems, such as the Tl, TIC, and FT4E-144 systems, as 
well as ISDN systems and other alternative carrier systems. 
These modifications, additions and substitutions are within 
the skiU of an ordinary skilled telecommunication engineer 
and are within the scope of the invention. 

As depicted by RG. 1, the illustrated trunk lines 20 
connect to an optional jack unit 18. Transmission path 24 
that connects between the jack 18 and the telecom unit 14 
can be conventional lead lines of the type commonly 
employed for connecting a telephone trunk jack with a PBX 
system. The depicted PBX telecom imit 14 includes a 
switching mechanism that establishes circuit connections 
between the depicted telephone tnmk lines 20 provided by 
the PSTN and one or more of the telephone units 16. The 
PBX telecom unit 14 establishes these circuit connections as 
a function of the information transmitted through the trunk 
lines 20 and the data and command signals received from 
chent/server applications running on the network 40. 

FIG. 1 further • depicts that the server 12 includes a 
network interface 38 which couples via network 40 to the 
cUent elements 42. Each element 42 is a conventional data 
processing element, such as a PC compatible computer, a 
VAX system, a UNIX system, or any data processing unit. 
The network interface 38 is understood to represent those 
elements of server 12 that operate the network 40. In one 
typical embodiment, the network interface 38 includes a 
network interface card of the type commonly used for 
connecting to a conventional computer network. 'ITie host 
processor element 38 typically further includes those ele- 
ments necessary fpr storing and operating a network oper- 
ating system (NOS) and for storing and running client/server 
applications. The network 40 depicted in FIG. 1 is a trans- 
mission path between the network interface card 38 and the 
client elements 42. 

In one preferred embodiment of the invention, the net- 
work is a Novell or Novell compliant network that runs 
(TSAPI) Telephony Services Application Programming 
Interface applications. However, it should be apparent to one 
of ordinary skill in the art that any computer network which 
interfaces plural computer elements and exchanges data and 
command signals between computer elements can be prac- 
ticed with the present invention without departing from the 
scope thereof. Moreover, the present invention can be prac- 
ticed with any CSTA compliant pubUc interface as well as 
other public interfaces including the (TAPI) Telephony 
Application Programming Interface system sold by the 
Microsoft company of Redmond, Washington. Additionally, 
it will be apparent to one of ordinary skill in the art of 
telecommunications and computer engineering that the 



10 



15 



20 



25 



30 



40 



45 



50 



55 



60 



65 



invention can be practiced with stand alone systems wherein 
a stand alone computer device directly interfaces with the 
telecom unit 14 for exchanging information therewith. 
Accordingly, it will be understood that in the stand alone 
embodiment of the invention the network components 
depicted in FIGS. 1 and 3 are unnecessary. 

One PBX telecom unit 14 is the PBX system 48 depicted 
in FIG. 2 that includes a TELCO connector 46 that connects 
to both subscriber lines and PSTN trunk lines, a trunk 
interface 50, a subscriber interface 52, a CODEC element 
54, a switch element 56, an ISA interface 60, a processor 
element 62, a RAM element 64, a ROM element 66, and an 
optional expansion interface 70. 

The TELCO connector 46 depicted in FIG, 2 is a con- 
ventional 50-pin TELCO RJ21X connector. In one embodi- 
ment of the invention, six analog trunks and eighteen 
extension lines come onto the PBX system via the connector 
46. Typically the PBX system 48 provides Une protection for 
each of the trunk and extension hnes that connect in circuit 
to the TELCO interface 46, In a preferred embodiment of the 
invention, the PBX system 48 provides a solid state auto 
resetting surge and lightning protector to protect each exten- 
sion and trunk line connected by TELCO connector 46. In a 
further preferred embodiment of the invention, PBX system 
48 includes a relay switch that connects in electrical circuit 
to the power supply of the PBX system 48. In the event of 
system power failure, the relays configure to switch one 
trunk Une through to one extension. Accordingly, in the 
event of power failure, the relay element establishes a 
dedicated telephone circuit connection between the PSTN 
and a designated one of the telephones, DTE's, DCE*s, 
DSE's, or any other end user machine. In an alternative 
embodiment, the PBX system 48 is an all extension line 
PBX system that includes an interface that connects only to 
internal extension lines for establishing call connections 
between these extension lines. 

The depicted trunk interface 50 couples the PBX system 
48 to the trunk lines of a PSTN system. Trunk interface 50 
includes an electrical circuit with solid state relays to control 
ring and hang-up detection, battery and ring feed, oflf-hook 
detection and 2:4 wire conversions. The trunk interface 50 
can connect to loop start trunks and can support DID and 
DNIS trunks. Optionally, trunk interface 50 includes caller 
ID logic to decode the trunk PSK format caller ID informa- 
tion for reading by the PBX system 48. In alternative 
embodiments of the invention, the trunk interface 50 can be 
adapted to couple the PBX system 48 to alternative carrier 
systems including Tl, fiber optic and ISDN lines. FIG. 2 
further depicts subscriber line interface element 52 that is a 
conventional subscriber line interface circuit and is config- 
ured similar to the trunk interface element 50. In one 
embodiment of the invention, the PBX system 48 is an all 
trunk PBX system that includes an interface to plural trunk 
lines for establishing call connections between the lines of 
the trunks. 

• CODEC element 54 can be a conventional CODEC 
element for converting analog signals of an analog trunk and 
subscriber lines to a pulse code modulated (PCM) serial data 
stream. In a preferred embodiment of the invention, the 
CODEC element 54 converts analog output signals to an 
8-bit /i law PCM serial data stream at a sampling rate of 
approximately 8 kilohertz. Alternatively, the CODEC ele- 
ments 54 can be of the type that employ linear encoding/ 
decoding techniques, such as the A law technique, for 
converting analog signals of the analog trunk and subscriber 
lines to a PCM serial data stream. Other coding processes 

, can be practiced with the present invention without depart- 
ing from the scope thereof. 
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Switch elemeol 56 is preferably a lime division multi- 
plexing (TDM) switching matrix of the type commonly 
employed for full digital switching. These switches are well 
known in the art of telecommunications and computer 
engineering for providing sufiBcient switching rates to 
accommodate the switching of PCM data. Preferably 
switching element 56 has a non-blocking architecture. 

In one preferred embodiment of the invention, switch 
element 56 is a MUSAC-based time switch. This switch 
receives eight 32-channel PCM streams and properly 
switches those channels to eight 32-channel output streams. 
Sixty-four of the overall 256 channels can participate in 
conferencing. The onboard controller properly adds together 
the conferenced channels and distributes back to the output 
stream. The controQer element can operate the switch so the 
64 conference channels can all be in one conference or be 
broken into smaller size conferences. The digital switch 
element 56 also provides the path from the stations/trunk to 
any voice processing hardware. Preferably all switching is 
digital to thereby allow that any station or trunk can employ 
voice processing functions available on the PBX system 48. 
One MUSAC digital switch element 56 suitable for practice 
with the present invention is the PEB 2245 switch manu- 
factured by the Siemens Corporation of Germany. 

FIG. 2 further depicts that controller element 62 connects 
via a bus 72 to a RAM element 64, ROM element 66, and 
a ISA PC bus interface 60. In one embodiment of the 
invention the controller element 62 includes a 20 megahertz 
Intel 80C186 microprocessor and two FPGA devices that 
couple to the microprocessor and implement support logic. 
The controller further connects to a 512KB static RAM 
element and a 256KB flash ROM element, which is prefer- 
ably a EEProm to allow for modification of onboard pro- 
grams. The RAM provides audio channel buffer space, 
board-to-host message storage space and configuration table 
storage space. The ROM contains storage space for a 
controller operating program that includes a calling interface 
which will be described in greater detail hereinafter. The 
CPU 62 controls operation of the ISA PC bus interface to 
control the exchange of message data units between the PBX 
system 48 and the LAN 40. Accordingly, these elements 
operate as the host interface 44 depicted in FIG. 1. 

In one embodiment the controller 62 operates responsive 
to a controller operating program within the ROM element 
66 that directs the controller and FPGA support logic 
through a series of tasks. The operating program provides 
instructions for time related tasks and interrupt related tasks. 
T\\G time related tasks include servicing the CODEC 
elements, typically every 125// seconds, controlling ring 
relays to turn ring relays on and off at a selected cadence, 
and time outs for off-hook alerts. The interrupt related 
activities include call processing such as off-hook/on-hook 
interrupts, caller Id service that typically services a UART 
port of the caller ID logic, board-to-board communication 
services, including servicing an HDLC circuit of the expan- 
sion interface 70, and operating the ISA interface for imple- 
menting a message bus that provides data exchange with the 
host 12, including message unit exchange and audio data 
exchange. The code for the board-to-board communications 
and for the calling interface are described in greater detail 
hereinafter. The call processing operating program follows 
from conventional principles of telecommunications and 
computer engineering and can be any call processing oper- 
ating program suitable for use with the depicted PBX system 
48, or suited for other telecommunication equipment accord- 
ing to the invention. 

In a preferred embodiment, the telecom unit 14 includes 
an onboard power supply 67 that supplies power to the 
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telecommunication equipment to maintain operation during 
deactivation of the server 12. In the depicted PBX system 48 
the controller element 62 includes an onboard power system 
that supplies power to each element depicted in FIG. 2 and 

5 to each telephone line supply. By providing the controller 
element 62 with an onboard power supply, the PBX system 
48 is able to maintain all processing ftinctions during 
shutdown of the server 12. Typically, the operating program 
includes call control functions that respond to commands 

3Q that are entered through the keypad of the telephone units 16 
to also allow more advanced call processing operations such 
as call transfers, call forwarding and other such operations. 

The PBX system 48 depicted in FIG. 2 includes an 
optional expansion interface 70. The expansion interface 70 

35 allows multiple telecom units, such as PBX system 48, to be 
coupled together to provide an expanded PBX system that 
• can receive and control additional trunk lines and subscriber 
lines. To this end, the depicted PBX system 48 has a modular 
design to allow for multiple ones of these PBX systems to 

20 be daisy chained together to form a larger PBX system with 
expanded capabilities. In the depicted embodiment, each 
PBX system separately includes elements for operating as a 
PBX system, including a TELCO interface, a CODEC, a 
switching component and a control processor. Accordingly, 

25 each system 48 is a complete system that provides all 
capabilities necessary to operate as an advanced PBX sys- 
tem. Each PBX system 48 further includes an onboard 
. jumper that is registered into a status register. The jumper 
provides a status signal that indicates which of the PBX 

30 systems 48 will operate as the master unit and control the 
exchange of data among the daisy -chained boards. Although 
this modular structure is a preferred embodiment of the 
invention, it will be apparent to those of ordinary skill in the 
art of telecommunications and computer engineering, that 

35 other system designs can be employed with the present 
invention to provide for expandable telecom units that can 
be integrated into a computer. 

One prefened expansion interface 70 is a PCM highway 
implemented through the SCSA bus standard to provide 

40 board-to-board switching. In one embodiment the expansion 
interface is an SCSA interface that includes a Dialogic SC 
2000 chip, manufactured and sold by the VTI Corporation. 
The SC 2000 chip is designed to facilitate the implementa- 
tion of PCM highways and thereby allow multiple telecom 

45 systems to be daisy-chained together to form larger systems. 
Additional board-to-board communication, such as time slot 
assignments on the PCM highway or call offerings, is 
performed by a Siemens communications chip such as the 
HDLC SAB82526 as \yell as the processor element 62. In 

50 the system depicted in FIG. 2, interboard communications 
. are interrupt driven. The expansion interface 70 provides an 
interrupt status line to the controller element 62. The inter- 
mpt status line connects to a FPGA of the controller element 
62 to drive the processor interrupt signal. The processor 

55 services the interface 70 to exchange data among the mul- 
tiple PBX systems 48 that are daisy-chained together. 
However, it will be apparent to one of ordinary skill in the 
art of telecommunications and computer engineering that 
other systems and processes for interboard communications 

60 can be practiced with the present invention without depart- 
ing from the scope thereof: 

FIG. 3 depicts in block diagram form the software archi- 
tecture of the networked CIT system 10 depicted in FIG. 1. 
As depicted in FIG. 3, a networked system 10 according to 

65 the present invention allows telephony enabled applications 
running on a client processor to control the operation of 
telecommunication equipment integrated into a server. A 



03/22/2004, EAST Version: 1.4.1 



5,875,234 

11 12 

telephony enabled client application runs on a client pro- oped and sold by the Microsoft Corporation of Redmond 
cessor such as the client element 42 depicted in FIG. 1. TTie Washington. However, any telephony service application 
client application software layer 80 interfaces with a tele- programming interface that supports telephony control capa- 
phony services application program interface 82, which bilities in a generic, switch independent way is suitable for 
interfaces with a cUenl network operating system interface 5 practice with the present invention. 
84, which allows the client application 80 to interface. Client application 80 and the telephony application pro- 
through network interface card (NC) 90, with the client gramming interface 82 employ the network operating sys- 
network operating system 86. The client network operating tem interface 84 to access the client NOS 86 for transferring 
system 86 provides, in part, for the exchange of information messages across the network 40 to the server element 
through the local area network element 40, thus providing integrated with the telecom unit 14. In one embodiment of 
for the transfer of data between the client element 42 and the the invention, the network operating system is the Novell 
server element 12. As further depicted by FIG. 3, a LAN Netware system sold by the Novell Corporation of Provo. 
adapter NIC 91 provides for the exchange of information Utah. However, it should be apparent to one of ordinary skill 
across the LAN 40. The LAN adapter NIC 91 provides in the art of telecommunications and computer programming 
hardware support for the network interface software 92, that any network operating system suitable for transferring 
which enables the server 12 to exchange information with message units over the network 40 can be practiced with the 
the client processors 42 on network 40. present invention without departing from the scope thereof. 

As further depicted by FIG. 3, telephony enabled server As further depicted by FIG. 3, the server, like the client 
applications 96 can run on the server 12 and interface with elements, can run telephony enabled applications, such as 
the telephony services application program interface (API) 20 Ihe telephony enabled server appUcation 96 depicted in FIG. 
94, which interfaces with the telephony service support layer 3. As described with reference to the client element, the 
92. The telephony service support layer 92 passes message telephony enabled server applications 96 can interface with 
units to the driver element 100 that employs the interrupt the telephony services application programming interface 
service routine 106 to exchange message units with the 94, which provides the capabilities for interfacing with a 
telephony API calling interface 116 that can exchange data 25 telecom unit for maintaining call control. The telephony 
and control signals with the telecom hardware control soft- enabled server application 96 and the application program- 
ware 118. ming interface 94 interface with the NOS 86 through the 

The depicted software architecture of FIG. 3 is represen- telephony service provider program 92 that allows messages 

tative of one suitable software architecture for a telecom unit to be passed between the server application 96 and the NOS 

14 that is integrated according to the present invention into 30 86. 

a computer network 40 for servicing cUent/server applica- FIG. 3 depicts that message units generated by the client 

tions running on the network. However, it will be apparent . application 80 for the server application 96 are passed 

to one of ordinary skill in the art of telecommunications and through the telephony service provider 92 to the driver 

computer engineering that other software architectures can element 100. The driver element 100 operates the interrupt 

be practiced with the present invention. For example, in a 35 service routine 106 for transferring message units under the 

stand-alone environment network software interfaces are control of the server network operating system NOS 87 to 

unnecessary and running applications can interface with a the software running on the telecom unit 14. In one embodi- 

library of functions that act as an application program ment of the invention, each message unit is a CSTA com- 

interface that can exchange data and control signals with the pliant data structure generated by the either telephony ser- 

telecom hardware control software 118. Other suitable soft- 40 vice application interface 82 or 94. 

ware modifications will be apparent to one of ordinary skill In the depicted embodiment, the driver element 100 

in the art of telecommunications and computer engineering. receives message units from the NOS 86 and stores the 

The telephony enabled client application 80 depicted in message units in a send buffer 102. The driver element 100 

FIG. 3 can be any telephony application that responds to or sends an interrupt to the interrupt service routine 106 which 

generates requests for any telecommunications equipment 45 activates the telecom unit 14 to collect the data from the send 

that has a physical and logical connection with the client buffer 102 and store it in the buffer 112 on board the telecom 

network operating system NOS 86. In one typical example, unit 14. Message units in the data buffer 112 are available to 

the telephony enabled client application 80 is a program that the calling interface 116 maintained on board the telecom 

monitors and directs incoming telephone calls by requesting unit 14. The calling interface 116 employs the message units 

from the telecom equipment 14 information representative 50 to operate the telecom hardware control software 118 that 

of a caller ID signal and correlating the caller ID signal with controls the hardware elements of telecom unit 14. 

a database of account information for transferring the As further depicted by FIG. 3, the telecom unit 14 

incoming telephone call to an appropriate telephone station provides a buffer element 114 that can be used for passing 

and for similariy forwarding the corresponding database message units from the telecom unit 14 to the server NOS 87 

information to the appropriate workstation. 55 ' and which operates in a similar manner as the interface 

As depicted in FIG. 3, the telephony enabled client between the driver 100 and the telecom unit 14. In a typical 

application 80 is a software program that employs a tele- operation, the hardware of the telecom unit 14 provides 

phony application programming interface 82 to operate the status or event information to the telecom hardware control 

telecom equipment 14. The telephony application program software 118, such as providing a line busy signal. The 

interface 82 is typically a collection of functions and data 60 telecom hardware control program 118 passes the status or 

structures that provide the necessary low level software event information to the calling interface 116 that generates 

commands suitable for describing the necessary telecom- a network compatible message unit. The calling interface 

munication operations and data exchanges that need to occur 116 provides the network compatible message unit to the 

to service the requests of the client application 80. One buffer 114 and indicates the buffer to be full. The interrupt 

suitable telephony application programming interface is the 65 service routine 106 detects the buffer full flag and signals the 

TSAPI interface developed and sold by the Novell Corpo- . driver element 100 to collect the message unit from the 

ration of Provo, Utah, another is the TAPI interface devel- buffer 114 and store the message unit into the receive buffer 
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104. Once the driver element 100 completes the read of 
buffer 114, the message unit stored in the receive buffer 104 
are passed to the server provider layer 92. The network 
operating system interface 92 reads the destination informa- 
tion of the message units, and routes the message units to the 
proper telephony enabled application program, such as the 
application programming interface 82 of the client applica- 
tion 80. The application programming interface 82 decodes 
the message unit and provides the necessary high level 
information to the client application 80. Client application 
80 responds to the high level information and proceeds with 
the application. 

With reference to FIG. 3 an example of a client telephony 
service request according to the invention can be described. 
The client application 80 makes a service call using the 
telephony application program interface 82. For example, 
the client application 80 can request to make a call through 
the telecom unit 14. In a preferred embodiment, the tele- 
phony application program interface 82, such as the Novell 
TSAPI or Microsoft TAPI public interfaces, includes a 
subroutine "make call" which conforms to the CSTA pro- 
tocol. The client makes the service request and the telephony 
application program interface 82 builds a message unit to 
transfer to the telecom unit 14. 

In a preferred embodiment of the invention, the telephony 
application program interface 82 builds a message according 
to the CSTA protocol. One such message unit Is depicted in 
FIG. 4. The message unit includes a driver control block 
(DCB) structure 121 and a request block 123. The DCB 
header includes ten information signals for classifying and 
routing the message to the telecom unit 14 and the request 
block 123 contains information for implementing the 
requested service. 

In the message unit depicted in FIG. 4, the DCB block is 
a data structure of -the type employed by the Novell TSAPI 
public interface. This block includes a message offset signal 
for identifying the relative memory location of the request 
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block 123, a message length block for indicating the size of 
the request block 124, and a class_of_service message 
signal to indicate the type of request being made by the 
client application. Other data signals, including private 
5 Offset, private length, sessionID, monitorCrossRefID and 
invoke ID are provided for uniquely identify ingthe message 
block and for providing header information that allows for 
the proper delivery by the system of the request block 124. 
Although the depicted DCB 122 represents DCB data struc- 
ture according to the Novell TSAPI public interface, it will 
be apparent to one of ordinary skill in the art of telecom- 
munications and computer engineering that any other suit- 
able public interface can be practiced with the present 
invention without departing from the scope thereof. 

The request block 123 depicted in FIG. 4 includes a 
callingDevice signal and a calledDevice signal. The call- 
ingDevice signal identifies the device initiating the call. For 
example, the calling Device signal can represent the internal 
extension line connected to the telecom unit 14. The called- 

• Device signal can indicate the telephone number being 
dialed by the telecom unit 14. The depicted request block 
124 represents a data structure of the Novell TSAPI public 
interface. However, any other suitable public interface can 
be practiced with the present invention without departing 
from the scope thereof. The telephony services application 
program interface 92 passes the message to the driver 100 
and, as described above, the driver 100 passes the message 
to the telecom unit 14. 

The calling interface 116 of the telecom unit 14 directly 
processes the message unit to operate the telecom hardware 

.control 118 and perform the requested service. In one 
embodiment, the calling interface 116 includes a dispatch 
and switch program element that operates on the message 
unit in the buffer 112. The structure of one embodiment of 
2 J a suitable calling interface dispatch and switch element can 
be described with reference to the following example code 
that illustrates the direct processing of a CSTA_MAKE_ 
CALL service. 



/• The following is an example of a platform neutral telephony service application 
••program public interfece message service that operates on a message unit 
*"in an input buffer. and produces a reply message unit in a result buffer. 

* 'Inputs: 

*• inBuffer pointer to incoming mcssa^ unit 

** outBuffer pointer to space for reply message unit (big enough for max) 
••Returns: 



•• -1 error or failure, failure message unit in outBufifer to be sent 

•• 0 error, could not build reply message unit 

•• 1 success, reply message unit in outBufifer to be sent 

LX)CALDEF int NBmessageHandler(void far •inBuffer, void far *outBuffer) 

/* declare pointers to the input and output buffers */ 

TDII>riverControlBlocl£_t far "inDCB - (TDIDrivcrControlBlockt_far ♦)inBuffer; 
TDII>ivcrControiBlocl£_t far •outDCB - (TDIDriverControIBlock_t far 
•)outBuffer; 

/• declare pointers for the message unit and the reply message unit •/ 
void fer "pMsg; 
void far "pRcply; 

/• check in the input and output buffer pointers are set ■/ 
if (outOCB « NULL) return 0; 
if (inDCB =- NULL) return 0; 

/* assign the pointers for the message unit and the reply message unit •/ 
pMsg = &((char far ") in DCBX inDCB-* messageOffiscti/' the message unit 
pointer is direaed to the request 

block 124'/ 

pReply = &((char Ear •)outBuffer)[sizcof(TDIDrivcrControlBlock_t)]; 
/• copy and initialize header information for the reply message unit */ 
_fmemcpy(outDCB,inDCB,si2eof(TDIDriverControlBlock_t)); 
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-continued 

outDCB-»private02set - 0; 
outDCB— privatcLength = 0; 

outDCB— messageOflfsct - sizcof(TDIDriveiCoatrolBlock_t>, 
outDCB ^messagcLcngth - 0; 

oulDCB^monitorCrossReHD - OW will be set as ihe message is shipped •/ 
/•Begin the dispatch and switch operation*/ 

switch (inDCB-^mcssageCIass) /* switch on the type of message 7{ 
case ACSREQUEST: 

outDCB— messagcClass = ACSCONFIRMATION;/' establish and 
intializc class of 

reply message unit */ 

switch (tnDCB-*mcssagcTypc)/* switch on message type */{ 



case CSTA_MAKE_CALL: /" the CSTA_MAKE_CALL code is 
activated */ 

{ 

UNE_ID callerlD; 
CALL_ID calllD; 

CSTAMakeCalLt far *pMake - pMsg; 
CSTAMakeCailCohfEvent^t far "pCall - pReply; 
outDCB -*messageLength 

- 5izeof(CSrrAMakeCallConfEvent_l);/*set size of reply 

message 

unit •/ 

outDCB— mcssageiype = CSTA_MAKE_CALL_CONF;/*set type 
of reply 
message unit */ 

callerlD = lookup Device I D(pMake—callingDevice)*y* get local 

representation of 

the caller V 

if (callerlD =- NO_UNE) { 
cstaFaUCoutDCBJNVALID_CALL[NG_DEVICB); 
return -1; 

}; 

/• create a phone call •/ 

calllD - callDeviceToDevice(callerID,pMake —called Device); 
if (calllD — NO_CALL) { 
cstaFailCoutDCB,INVALlD_CALXED_DEVICE); 
return -1; 

}; 

pCal!— newCall.calllD = encodcCalllD(calltD)-/* create an externa) 

representation of an 

internal catllD*/ 

_f me mcp y(pCall — ncwCall .device ID,pMakc — ca UingDevicc, 
DIMCpCal 1— newC&lLdcviccID));/ 

pCall— newCall.dcvIDIVpe » STATIC_ID;/* define the type of 
device ID created •/ 

return 1; 
} 



} 

defeult; 

}; 

return 0; 



As can be seen {rona the above code, the calling interface 
116 collects the message unit from the buffer 112 whose 
location in the host 12 memory is given by the variable 
inBuffer. Once the message unit is collected, the calling 
interface 1 16 accesses the information in the DCB block 
121 and request block 123 to operate the switching of the 
telecom unit 14. 

First, the calling interface 116 accesses the inDCB — 
>messageClass signal to determine the type of class of the 
request being made by the client application 80. This allows 
the calling interface 116 to determine the type of reply 
message unit to generate and to transfer back to the client 
application 80. In the example, the message unit is of class 
ACSREQUEST, and the caUing interface 116 sets the reply 
message unit outDCB — >messageaass signal to ACSCON- 
HRMATION. 



In a subsequent step, the calling interface 116 accesses the 
segment of the message unit, inDCB — >messageType, that 
identifies which service request was made by the client 

^5 application 80, Once the type of service request is deter- 
mined. The code accesses the telecom hardware control 
program 118 to operate the switching element 56 to imple- 
ment the requested service. For example, in response to the 
make_call request, the calling interface 116 calls the call- 

60 . DeviceToDeviceO function to configure the switch 56 and to 
return a message that identifies the newly established con- 
nection. 

As further illustrated by the above example code, the 
calling interface 116 also prepares a reply message unit for 
65 U-ansferring to the client application 80. In the example code, 
the reply message unit is a make_call_confirm type given 
by the signal CSTA^M AKE_CALU_COW. As described 
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above with reference to FIG. 3, the calling interface employs 
the interrupt service routine to transfer the reply message 
buffer to the telephony service layer 92, which can transfer 
the reply message unit to the client application 80. This reply 
message unit provides the client application 80 with infor- 5 
mation to continue processing the telephony application. 

The above describes a transfer of message units between 
a client application 80 and the calling interface 116 of the 
telecom unit 14 where the message units include data that 
instruct the telecom unit 14, in this case a PBX system, to 10 
perform call control and other functions. However, the 
telecom unit 14 and the server 12 can also exchange audio 
data. In this further embodiment of the invention, the server 
element 12 includes a file memory that contains files of 
audio information. The client application 80 and calling 35 
interface 116, described above, can play audio information 
by queuing up audio files stored in the file memory and 
transferring data from these audio files between the server 
12 and the telecom unit 14. This audio data can be played 
through the switch 56 and CODEC elements 54 to a handset 20 
16 or other device. Similarly, the client application 80 and 
calling interface 116 can be employed to record audio 
information received through a handset 16, digitally 
encoded by the CODEC elements 54 and transferred by the 
calhng interface 116 to an audio file stored for example on 25 
the server element 12. 

In operation the system 10 plays an audio file, such as a 
prerecorded voicemail message, by the client application 80 
queuing an audio file stored on the server 12 and transferring 
the audio file to the telecom unit 14. In one example, the 30 
client application 80 passes, as described above, a message 
unit that instructs the telecom unit 14 to play an audio file 
stored on the system, such as on the server 12 to a particular 
caller. The audio file can be any file of information that 
encodes audio information in a format suitable for transfer 35 
to the telecom unit 14. In one embodiment of the invention, 
the telecom unit 14 is a PBX system and the audio file 
contains digital information representative of digitally 
encoded voice signals which are suitable for transferring to 
the PBX system 14 and being passed through the CODEC 40 
element 54, to generate audio signals for the handset 16. 

The telecom unit 14 reads the message unit passed by 
client application 80 and identifies the caller who is to 
receive the audio information. The telecom unit 14 through 
calling interface 116 passes, as described above, a message 45 
unit back to the client apphcation 80 instructing the client 
application 80 to pass the audio file to an internal buffer. In 
one embodiment of the invention the client application 80 
receives the message unit from the calling interface 116 and 
transfers the audio file to the buffer 102 providing the 50 
transfer on a continuous basis until the end of the audio file 
is reached. Once the calling interface 116 has received the 
audio file information, it can transfer this information to the 
caller of interest. In one embodiment of the invention, the 
telecom unit 14 reads the audio information from an internal ss 
buffer one byte at a time on a continuous basis. Each byte is 
transferred immediately to a dedicated channel of the switch 
56 which is configured to transfer the audio information to 
the proper device. Each byte is transferred until the end of 
the file is reached. A record audio function operates in a 60 
similar manner as the play audio feature described above 
with the sequence of steps occurring in the reverse order. It 
will be apparent -to one of ordinary skill in the art of 
telecommunications and computer engineering that any sys- 
tem suitable for transferring a file of audio information from 65 
the server 12 to the telecom unit 14 can be practiced with the 
present invention without departing from the scope thereof. 



■ Moreover, it will similarly be apparent to one of ordinary 
skill in the art of telecommunications and computer engi- 
neering that the described play audio and record audio 
feature can be practiced with the present invention config- 
ured in a stand-alone computer system that includes one or 
more files of audio information. 

In another embodiment of the present invention, the 
system 10 described herein can be configured to receive 
audio data files from remote network locations and for 
playing these audio data files to the telecom unit 14 for 
transfer to a telephone unit 16. The system 10 can be adapted 
to record audio data files and transfer these audio data files 
through a network system to be played at a remote location. 
In this way, the system 10 can be configured with two or 
more server integrated PBX systems, internetworked 
together to pass files between the server elements. In this 
configuration, connections can be established across the 
internetworked system to employ the computer network as 
a phone network system. 

One such internetworked system 120 is depicted by FIG. 
5. FIG. 5 illustrates an internetworked system 120 that 
includes a first server integrated PBX system 122, a second 
server integrated PBX system 124, an internetwork interface 
126 coupled to the system 122, an internetwork interface 
128 coupled to the system 124, and an internetwork trans- 
mission path 130 connected between the internetwork inter- 
face elements 126 and 128. 

As depicted in FIG. 5, the system 120 provides an 
internetwork interface between the two network servers 122 
and 124, each of which is constructed according to the 
present invention. The internetwork connection can be any 
type of internetwork connection for transferring information 
between two or more networks, for example, it can comprise 
a TCP/IP network interface. It will be apparent to one of 
. ordinary skill in the art of telecommunications and computer 
engineering that any interface suitable for exchanging infor- 
mation between two network systems can be practiced with 
the present invention without departing from the scope 
thereof. 

As depicted in FIG. 5, the server 122 includes a telecom 
unit 14 according to the present invention, telephone units 
16, and client elements 42 connected to the server element 
via the network 40. In one embodiment of the invention a 
client application 80 running on a client element 42 monitors 
the incoming calls to the telecom unit 14 which is a PBX 
system according to the invention. The client application 80 
identifies each called device, such as an internal extension 
line connected to a telephone unit such as one of the depicted 
telephone units 16. The client application 80 includes a table 
that identifies the network location of each interface, includ- 
ing each internal extension line. If an incoming call to server 
122 is directed to a device connected to the PBX server 14 
of the system 124, the client application 80 can provide the 
incoming call with access to the record audio system 
described above, allowing the incoming caller to create a 
voicemail audio data file. Upon termination of the incoming 
call, the client element 80 transfers the voicemail audio data 
, file to the internetwork interface 126 that transfers the 
voicemail audio data file via the network transmission path 
130 to the internetwork interface 128 of system 124. The 
internetwork interface element (INI) 128 can store the voice 
message audio data file in the appropriate location of file 
memory so that the system 124 can indicate to the called 
device that a recorded voice message is available to be 
accessed. In this way, the system depicted in FIG. 5 allows 
for the transfer of audio data signals between telephone 
devices, such as the telephone unit 16, that are physically 
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connected to different network systems. Although the sys- 
tem is described with reference to a voicemail application, 
it will be apparent to one of ordinary skill in the art that real 
time voice data may also be exchanged without departing 
from the scope of the present invention. 

As can be seen from the above description, the telecom 
unit 14 provides a telephony API calling interface 116 that 
responds to and generates LAN — compatible message units. 
In a preferred embodiment of the invention, the telephony 
API calling interface handles calls using the CSTA standard 
model. However, other CIT standard definitions for com- 
puter supported telecommunications can be practiced with 
the invention without departing from the scope thereof. It 
will also be appreciated by those skilled in the art that 
changes can be made to the embodiments described above 
without departing from the broad inventive concept thereof. 
For example, certain elements of the illustrated embodi- 
ments are described as circuit card assemblies or software 
modules; however, it will be apparent to one of ordinary skill 
in the art that the embodiment of these elements as software 
or hardware modules can typically be interchanged or 
supplemented depending upon system requirements includ- 
ing speed of processing, size, expense or other design 
criteria. It is understood, therefore, that this invention is not 
limited to the particular embodiments disclosed, but it is 
intended to cover modifications within the spirit and scope 
of the present invention as defined by the appended claims. 

We claim: 

1. A PBX system implemented on a printed circuit board 
and adapted for interfacing to a server of a computer 
network, comprising ^ 

a carrier interface for coupling to a plurality of carrier 
fines suitable for transmitting signals, including power, 
to at least one telephone handset, 

a subscriber interface for coupUng to s plurality of sub- 
scriber fines, each of said subscriber lines suitable for 
transmitting signals to said at least one telephone 
handset, 

a server interface having a bus port adapted for connect- 
ing to a bus slot of said server to form a data path with 
said server, 

a controller element in electrical circuit with said bus port 
for transferring message units across said data path and 
for generating control signals responsive to said mes- 
sage units, 

an audio element for transferring voice messages to said 
carrier interface, and coupled to a ROM for storing said 
voice messages, 

a sv^tch element for estabfishing circuits between said 
carrier fines and said subscriber fines, 

a power interface for receiving electrical power from said 
server to electrically power said system, and said at 
least, one telephone handset wherein said at least one 
telephone handset is directly connected to and powered 
by one of said carrier lines when electrical power is not 
received by said power interface from said server. 

2. A system according to claim 1 wherein said carrier 
interface comprises a trunk interface for coupling to a trunk 
fine. 

3. A system according to claim 1 wherein said subscriber 
interface comprises a subscriber loop interface for coupling 
to a plurafity of extension lines. 

4. A system according to claim 1 wherein said controfier 
element includes a processor element and is connected to a 
memory element having a caUing interface element for 
operating said processor element to generate said control 
signals responsive to said message units. 



15 



20 



25 



30 



35 



40 



45 



50 



55 



60 



65 



5. A system according to claim 4 wherein each said 
message unit includes a message-type signal and said calfing 
interface element includes a switch element responsive to 
said message-type signal for generating said control signals. 

6. A system according to claim 4 wherein said calfing 
interface element is adapted to operate said controfier ele- 
ment responsive to CSTA (Computer Supported Telephony 
Application) compfiant message unit. 

7. A system according to claim 4 wherein said calfing 
interface includes means for generating message units for 
transfer to said server interface. 

8. A system according to claim 7 wherein said means for 
generafing message units includes means for generafing 
CSTA (Computer Supported Telephony Application) com- 
pfiant message units. 

9. A system according to claim 4 wherein said memory 
element comprises a read only memory element for storing 
said caUing interface element as embedded code. 

10. A system according to claim 1 further comprising an 
exchange interface for coupling to a second system for 
exchanging message units between plural systems. 

11. A system according to claim 10 wherein said exchange 
interface included an SCSA (Signal Computing System 
Architecture) interface for providing a daisy chain interface 
among plural systems. 

12. A system according to claim 1 wherein said controller 
element includes audio data transfer means for transferring 
data representative of audio signals to said server. 

13. A system according to claim 1 wherein said controller 
element further includes a memory element for storing a call 
control program element for controlfing said switch element 
to implement a set of telecommunication functions. 

14. A system according to claim 13 further comprising an 
onboard power supply element for supplying power to said 
controfier element for fault tolerant operation, 

15. A network server system, comprising a message bus 
for carrying message units to a server, 

a branch exchange element having 

a server interface element for controlling the transfer of 

said message units across said message bus, 
a bus. port connected to said message bus for forming a 

data path, 

a trunk interface for coupfing to one or more trunk lines, 
a subscriber loop interface for coupling to a plurality of 

extension lines to carry signals to at least one telephone 

handset, 

an audio element for transferring voice messages to said 
tnmk interface, and coupled to a ROM for storing said 
voice messages, 

a controller element in elfectrical circuit with said bus port 
for transferring said message units across said data path 
and for generating control signals responsive to said 
message units, 

a switch element, in electrical circuit with said controller 
element, for establishing, responsive to said control 
signals generated by said controller element, circuits 
between said plural extension fines and said tnmk fine, 
and 

a power interface for receiving electrical power firom said 
server to electricaUy power said system, and said at 
least one telephone handset, 

wherein said at least one telephone handset is directly 
connected to and powered by one of said trunk lines 
when electrical power is not received by said power 
interface from said server. 
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16. A network server system according to claim 15 
wherein said controller elements; includes audio data trans- 
fer means for transferring data representative of voice sig- 
nals to said server interface element. 

17. A network server system according to claim 15 
wherein said server interface element further comprises a 
play audio element having 

data memory means for storing audio files of audio 

information, and 
audio file transfer means for transferring said audio files 

as messages to said branch exchange element. 

18. A network server system according to claim 16 
including internetwork interface means for transferring said 
data representative of voice signals to another network 
system. 

19. A telecommunication system adapted for interfacing 
to a computer, comprising 

a trunk interface for coupling to a trunk line, 
a subscriber loop interface for coupling to a plurality of 
extension lines to carry signals to a telephone, 
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a computer interface having a bus port adapted for con- 
necting to a bus slot of said computer of form a data 
path with said computer, 
a controller element in electrical circuit with said bus port 
for transferring message units across said data path and 
for generating control signals responsive to said mes- 
sage units, and 
a switch element, in electrical circuit with said controller 
element, for establishing, responsive to said control 
signals generated by said controller element, circuits 
' between said plural extension lines and said trunk line. 
20. A telecommunication system according to claim 19 
wherein said controller element includes a processor ele- 
. ment and a calling interface element for operating said 
processor element responsive to said message units. 
15 21. A telecommunication system according to claim 20 
wherein said message units include a message-type signal 
and said calling interface element includes a switch element 
responsive to said message-type signal for generating said 
control signals. 

* * * * * 
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